A cluster storage environment may comprise one or more storage clusters. A storage cluster may comprise one or more nodes. A node may be configured to provide client devices with access to user data stored on storage devices. Nodes may be configured according to various policies, such as a high availability policy where two nodes are paired together such that a primary node actively services client I/O requests and a partner node passively waits to provide failover recovery operation on behalf of the primary node in the event the primary node experiences a failure. Various issues, such as an inability for clients to access user data, may arise when information is not reliably replicated between nodes and/or storage clusters, when cluster-wide outages are not detected, and/or when failover operation is not implemented in an efficient manner.
In an example, a primary node, within a first storage cluster, may host a primary storage virtual machine within which objects, such as volumes, LUNs, data objects, and/or other configuration objects (e.g., a size of a volume, data access functionality, network access functionality, etc.) may be stored. A secondary node, within a second storage cluster, may host a partner storage virtual machine within which configuration of the partner storage virtual machine may be replicated (e.g., a creation of a LUN, a deletion of a volume, a resizing of a volume, and/or other changes to objects at the primary storage virtual machine may be replicated to the partner storage virtual machine). A logical stream may be created between the primary storage virtual machine and the partner storage virtual machine. Changes to objects of the primary storage virtual machine may be transferred over the logical stream to the partner storage virtual machine as configuration updates. If an asynchronous replication mode is used, configuration updates may be queued into a queue. Queued configuration updates may be read from the queue and applied to the partner storage virtual machine based upon recovery point objectives (RPO) set by a user.
Unfortunately, substantial amounts of network bandwidth, processing resources, database transactions, CPU usage, and/or other computing resource usage may be needlessly wasted on redundant, stale, and/or irrelevant configuration updates. In an example, a create volume configuration update for a volume (A) and a subsequent delete volume configuration update for the volume (A) may be queued, and thus resources used to perform the create volume configuration update may be wasted because the volume (A) will be subsequently deleted by the delete volume configuration update. In another example, a create volume configuration update for a volume (B) and a subsequent modify volume configuration update to increase the size of the volume (B) from 1 GB to 2 GB may be queued, and thus resources may be wasted to perform 2 separate configuration updates for a result that could otherwise be achieved by a single modified create volume configuration update to create the volume (B) at 2 GB as opposed to 1 GB.